home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.cs.arizona.edu
/
ftp.cs.arizona.edu.tar
/
ftp.cs.arizona.edu
/
icon
/
newsgrp
/
group94b.txt
/
000060_icon-group-sender _Tue Sep 20 13:38:49 1994.msg
< prev
next >
Wrap
Internet Message Format
|
1995-02-09
|
2KB
Received: by cheltenham.cs.arizona.edu; Tue, 20 Sep 1994 12:32:53 MST
Date: Tue, 20 Sep 1994 13:38:49 +0600
From: jeffery@runner.jpl.utsa.edu (Clinton L. Jeffery)
Message-Id: <9409201838.AA20878@runner.utsa.edu>
To: eddie@festival.ed.ac.uk
Cc: icon-group@cs.arizona.edu
In-Reply-To: <CwFnHC.Ds9@festival.ed.ac.uk> (eddie@festival.ed.ac.uk)
Subject: Re: Icon - still alive??
Content-Length: 1173
Errors-To: icon-group-errors@cs.arizona.edu
Eddie Corns writes:
> Rather than try to reshape the language for system tasks, perhaps
> we could simply extend the I/O interface so that, given a suitable
> bit of code, we could open anything from a TCP socket to... whatever.
> If this all went through the open/read/write interface there would be
> no loss of portability and no trying to change the language...
> There would probably need to be an equivalent to ioctl as well.
This is a good starting point. One can start with a nice, clean, file-based
model, and add many of these capabilities with no change to the language.
Once an initial implementation is working, experience suggests that:
(a) there will be *pressure* to add features ad nauseum, until it is
hideous, complex, and hard to learn.
(b) there will be *potential* to significantly improve the interface by
adding language support in the form of control structures, keywords,
etc. For example, ioctl() is ugly, and there may be nicer notations
for manipulating connections waiting to be discovered.
Clint Jeffery
cjeffery@cs.arizona.edu, jeffery@ringer.cs.utsa.edu
The University of Texas at San Antonio